[レポート]Amazon Aurora Multi-Master:書き込み性能のスケールアウト #DAT404 #reinvent

はじめに

こんにちは、崔です。

セッションDAT404-R：Amazon Aurora Multi-Master:Scaling out database write performanceに参加しましたので、そのレポートをお届けします。

セッション概要

In this session, learn how the Multi-Master capability of Amazon Aurora MySQL enables applications to scale out write performance and achieve continuous read/write availability. Engineering experts dive into the design concepts of Aurora Multi-Master and provide real-world advice on deploying high-throughput, highly available workloads in Aurora.

このセッションでは、Amazon Aurora MySQLのマルチマスター機能により、アプリケーションが書き込みパフォーマンスをスケールアウトし、連続的な読み取り/書き込み可用性を実現する方法を学びます。エンジニアリングの専門家は、Aurora Multi-Masterの設計概念に飛び込み、高スループットで可用性の高いワークロードをAuroraにデプロイするための現実的なアドバイスを提供します。

スピーカー

• Steve Abraham - Principal Lead Data Architect, Amazon Web Services
• Eric Boutin - Software Development Manager, Amazon Web Services

Agenda

• Architecture deep dive
• Best practices

Read and write scale out

• read scaling
  • 物理的な変更によるページキャッシュのアップデート
  • レプリカでは書き込みできない
  • シェアードストレージ
• Multi-Master
  • 物理的な変更によるページキャッシュのアップデート
  • 全てのインスタンスで書き込みトランザクションを実行可能
  • 楽観的コンフリクト検出によるシェアードストレージ

Decoupled transaction execution

• 2つのマスターノードによる更新
• それぞれのノードが自分の書き込みをチェック
• 別のノードの書き込みによりレプリケーション遅延が発生する
• トランザクションは全ての書き込みが確定してからコミットされる

Nonconflicting write

• 別テーブルへの異なるライターノードによる書き込みはコンフリクトは発生しない

Physical Conflict

• 同じテーブルへの別々のライターノードによる書き込みはコンフリクトが発生する
• どちらかのトランザクションがロールバックされる

Logical conflict

• 同じテーブルへの別々のライターノードによる書き込みはコンフリクトが発生する
• コミット前の更新に対する別ノードによる更新はロールバックされる

Conflict detection summary

• Aurora Multi-Masterは楽観的なコンフリクト対策をとっている
• ストレージノードがコンフリクトに対応している
• コンフリクトが解決された後に、トランザクションはコミットされる

Consistency model

• Instance Read-After-Write
  • 全てのトランザクションは事前にインスタンスでコミットされ、他のノードのトランザクションはレプリカラグの対象となる
• Regional Read-After-Write
  • クラスタ内の全てのトランザクションが事前にコミットされることを、トランザクションは観測できる

Scalability

• マルチマスターの場合は、Read/Writeともに2倍が見込める

Scaling writes/seconsd in Aurora Multi-Master

• インスタンス１がオフラインになると性能が半分に
• インスタンス１を8xlargeで立ち上げると、性能は向上

Failover time for an unmodified application

• Multi-Masterは10秒程度
• Single Writerは50秒程度

Best practices

Connecting to the cluster

• クラスタエンドポイントはアベイラブルなインスタンスに従う
• フェイルオーバーによりクラスタエンドポイントは変わる
• 各インスタンスはインスタンスエンドポイントを持つ
• カスタムエンドポイントも利用可能

Availability best practices

• アプリケーションはアプリケーションレイヤーで両方のライターノードに接続する
• アプリケーションレイヤーでライターノードのアベイラビリティをモニターし、利用可能なインスタンスにリダイレクトする
• クラスターエンドポイントは利用可能なインスタンスに従う

Summary

• 書き込みスループットを上げるために複数のライターノードを所有できる
• 継続的な可用性のために、複数のAZにライターノードを所有できる
• Aurora MySQL5.6で利用可能

まとめ

現在のAurora Multi-Masterは、Aurora MySQL5.6でしか使えません。
しかしながら、書き込み性能の向上やフェイルオーバー時間の短縮などが素直に見込めるため、コンフリクト処理を検証しながら利用する機会を検討してみたいなと思いました。